8.6. AAIF

Why does neutral governance matter for an agent stack?

MCP was one vendor's protocol. Anthropic donated it in December 2025 to the Agentic AI Foundation (AAIF), the Linux Foundation home for open agent infrastructure.

The vendors that compete on agent products now co-govern the contract they all depend on. That is the general rule in one case: whoever governs a contract decides how it evolves, who may change it, and whether a competitor's implementation stays interoperable.

An agent stack is mostly software you did not write and protocols you do not control: the model client, the tool protocol, the agent-to-agent wire format, the router, the metrics format. When one vendor owns a protocol, three risks follow:

1. The contract can drift to suit that vendor's product.
2. Your implementation can be pinned to their runtime.
3. A hostile fork can fragment the ecosystem.

Neutral foundation governance is the usual defence. A project donated to an independent foundation gets three things:

1. An open technical charter: the public document stating how the project makes decisions.
2. A public governing board, so no single company can unilaterally relicense or redirect it.
3. OSI-approved licensing: a licence reviewed and approved by the Open Source Initiative.

The contract then evolves in the open across vendors, and multiple implementations can conform to one published spec.

That is why this course prefers foundation-homed contracts at its boundaries — MCP for tools, A2A between agents, OpenTelemetry for signals — over any one vendor's proprietary SDK.

But be precise about what governance buys. A neutral home is a governance signal, not a technical guarantee. It does not promise API stability, security, or that two conformant implementations interoperate on the first attempt.

So the course does two things at once. It builds on open contracts, and it pins concrete versions and verifies them together. Governance decides who can change a contract; the pins in AGENTS.md decide what you actually run. This page answers the governance-home question: who stewards each project, and why that matters.

What is the AAIF?

The Agentic AI Foundation is a Linux Foundation home for open agent infrastructure, formed in December 2025. Its founding contributions were Anthropic's MCP, Block's goose agent runtime, and OpenAI's AGENTS.md convention; Solo.io's agentgateway joined in 2026 as the fourth hosted project. Platinum members include the major model and cloud vendors, which is exactly the point: a neutral board and technical committee let competitors co-govern the protocols they all depend on instead of one of them owning the spec.

Foundation governance gives these projects a vendor-neutral place to evolve. It does not by itself guarantee API stability, security, or compatibility with every implementation. Treat AAIF membership as a durability and openness signal, not a version-stability promise — the same caution 0.3. Ecosystem applies to the v1alpha2 and pre-2.0 surfaces the course pins.

Which AAIF projects appear in the course?

Three of the AAIF's four hosted projects are used here. The fourth, goose, is not: the course builds its agent on Google ADK instead. A foundation catalog is a menu, not a mandate.

1. MCP is the tool/context client-server contract. The agent reads incidents over MCP; 3.3. MCP implements the server and 5.2. MCP Gateway fronts it.
2. agentgateway is the open-source Rust data plane that routes MCP, A2A, and OpenAI-compatible model traffic; Chapter 5 owns it end to end.
3. AGENTS.md is the coding-agent instruction convention, covered in its own answer below.

A2A is closely related but distinct in governance: the Agent2Agent protocol was contributed to the Linux Foundation and is fronted natively by agentgateway, rather than being one of the AAIF's four hosted projects. The course uses it for agent discovery and task exchange (3.6. A2A, 5.3. A2A Gateway).

An open protocol is a wire contract, not an operational system. MCP says how a tool is discovered and invoked. It does not authenticate the caller, authorize which tools they may use, validate arguments, redact sensitive output, observe the call, or own the workload's lifecycle.

Adopting the protocol is the easy part; everything around it is the rest of the course. Those layers are:

1. Authentication and authorization: agentgateway policies — the six-tool MCP allowlist, per-listener rate limits, and enforced apiKey — in 5.5. Gateway Security.
2. Validation and safety: typed tool arguments, human approval for writes, PII redaction, and prompt-injection neutralization in 4.5. Guardrails.
3. Observability: OTLP traces, span-derived RED metrics, and correlated logs in 7.2. Monitoring.
4. Lifecycle ownership: kagent runs the A2A workload as a Kubernetes Agent resource in 6.0. Platform.

flowchart TD
    P["Open protocol contract<br/>MCP tools · A2A tasks"]
    P --> Auth["Auth + authz<br/>agentgateway allowlist,<br/>rate limits, apiKey<br/>(Ch.5 · 5.5)"]
    P --> Val["Validation + safety<br/>typed args, approval,<br/>PII redaction, injection guard<br/>(4.5 Guardrails)"]
    P --> Obs["Observability<br/>OTLP traces,<br/>RED metrics, logs<br/>(Ch.7)"]
    P --> Life["Lifecycle ownership<br/>kagent Kubernetes<br/>Agent resource<br/>(Ch.6)"]

Where does AGENTS.md fit?

AGENTS.md is a vendor-neutral repository convention that gives coding agents project-local instructions, adopted across many editors and agent tools. It is one of the AAIF's three founding contributions (donated by OpenAI), so it sits in the same neutral-governance landscape as MCP and agentgateway rather than being a private convention. This repository dogfoods it: the root AGENTS.md is the operating contract for agents working in the course, and Chapter 1 teaches the convention itself.

Keep one distinction sharp. AGENTS.md is a documentation/instruction standard, not a runtime protocol — no service speaks it. It governs how an agent edits this repository, not how the AgentOps Agent serves traffic. That is why it is a foundation-governed convention yet never appears in the network contract.

Which governance body stewards each part of the stack?

The stack's components sit in four governance homes. AAIF and CNCF are Linux Foundation sub-foundations; A2A and MLflow are direct Linux Foundation projects.

CNCF grades projects Sandbox → Incubating → Graduated by adoption and production use, so the tier below is a maturity signal.

1. AAIF (Linux Foundation): MCP and agentgateway, plus AGENTS.md as a convention. The neutral home for agent protocols and the data plane.
2. CNCF (Linux Foundation): Kubernetes, Prometheus, and OpenTelemetry are all CNCF Graduated projects (OpenTelemetry reached that top tier in May 2026, alongside long-graduated Kubernetes and Prometheus); kagent is a CNCF Sandbox project. Sandbox is the earliest tier — which is exactly why the repo pins kagent's stable chart 0.9.12 and treats its v1alpha2 API as movable compatibility work.
3. Direct Linux Foundation projects: A2A and MLflow. A2A was contributed by Google; MLflow was donated by Databricks in 2020 and is chartered as a Series of LF Projects, LLC. MLflow remains Apache-2.0.
4. Vendor / company stewardship (no independent foundation): Google ADK (Apache-2.0, published by Google), Grafana and Loki (AGPL-3.0, controlled by Grafana Labs through a contributor licence agreement), the Ollama local runtime, and the Qwen3 open weights (Apache-2.0, from Alibaba).

A contributor licence agreement is the signed grant that lets one company relicense contributed code.

flowchart TD
    LF["Linux Foundation"]
    LF --> AAIF["AAIF<br/>MCP · agentgateway<br/>AGENTS.md"]
    LF --> CNCF["CNCF<br/>Kubernetes · Prometheus<br/>OpenTelemetry (Graduated)<br/>kagent (Sandbox)"]
    LF --> Direct["Direct LF projects<br/>A2A protocol · MLflow"]
    Vendor["Vendor / company stewardship"]
    Vendor --> ADK["Google ADK<br/>Apache-2.0"]
    Vendor --> Graf["Grafana · Loki<br/>Grafana Labs · AGPL-3.0"]
    Vendor --> Run["Ollama runtime<br/>Qwen3 weights · Apache-2.0"]

Diagram in words: The Linux Foundation directly hosts A2A and MLflow, and also contains the AAIF and CNCF homes used by this stack. AAIF hosts MCP, agentgateway, and AGENTS.md; CNCF hosts the three Graduated infrastructure projects and Sandbox-stage kagent. Google ADK, Grafana, Loki, Ollama, and Qwen3 remain under company stewardship.

Governance tells you who may change a contract. It does not tell you whether your pinned version is stable, and it does not tell you what a licence obliges you to do.

How does the course stay provider-portable?

Part I uses native Gemini; the gateway-backed platform uses ADK's OpenAI-compatible client.

Moving between them changes the provider selection, endpoint, and credential ownership. A common API shape does not guarantee identical tools, streaming, errors, or model behavior. A provider swap counts as supported only after its recorded evaluation cases pass.

How can you contribute upstream responsibly?

Hitting a bug in software you did not write gives you two choices: carry a local patch forever, or fix it at the source.

Fixing it at the source means the whole ecosystem benefits and you stop maintaining a fork. Neutral governance is what makes that option viable: an open contribution process, a public issue tracker, and a published security policy you can actually follow. Do it cleanly:

1. Reproduce the issue against the project's current supported version, not just your pinned one — a maintainer will ask.
2. Remove course/provider-specific secrets and runtime state, and include a minimal protocol/config example rather than the whole repository.
3. Follow the upstream project's own security and contribution process; never file exploit details or credentials in a public issue.
4. Link any course workaround so others can find it while the upstream fix lands.

The common pitfall is filing at the wrong boundary. A gateway routing bug belongs to agentgateway, a v1alpha2 schema surprise to kagent, a tool-protocol question to the MCP spec, a trace-export bug to OpenTelemetry — not to this course. Fixing upstream can benefit the ecosystem more than indefinitely carrying a local patch. Improving the course itself is a different, in-repository workflow.

Use the narrow tracker that owns the failing side of a boundary:

Which pages own the neighbouring topics?

This page answers one question: who governs each contract. Five neighbours answer the rest.

1. 0.3. Ecosystem: which tool owns which runtime boundary.
2. 0.4. Providers: the open-source-versus-proprietary provider split.
3. 5.4. Model Gateway: the mechanics of the provider swap, and why it survives even a change to Vertex Gemini on GKE.
4. 8.0. Repository: the repository-layout side of the AGENTS.md dogfooding.
5. 8.5. Contributions: improving the course itself, in-repository.

What proves this page worked?

Start with a routing this repository already documents. The pinned gateway (v1.4.1) accepts MCP session termination with 202. The pinned MCP Python client's automatic closer recognizes only 200/204, so it warns after a request that in fact succeeded (5.2. MCP Gateway).

Neither side of that disagreement is this course. It routes to agentgateway under the AAIF, or to the MCP client project.

Now route two of your own, using the governance list above and nothing else:

1. kubectl apply rejects a v1alpha2 field your kagent manifest sets.
2. A span never reaches the collector and the exporter logs an OTLP error.

When you do hit a real issue, route it with the governance map above: the course repository (8.5. Contributions), the AAIF (MCP or agentgateway), the Linux Foundation (A2A or MLflow), the CNCF (kagent, Kubernetes, Prometheus, OpenTelemetry), or a vendor (ADK, Grafana). File it at the narrowest responsible boundary, with sanitized evidence and the exact pinned versions from AGENTS.md, and note whether you are carrying a local workaround while the fix lands. Getting the boundary right is the whole skill: it is the same discipline the rest of this stack is built on — one owner per contract, verified where it is pinned.

You are done when:

• You can name the governing body for MCP, agentgateway, kagent, MLflow, and Grafana without scrolling back up.
• You routed both hypotheticals above to a named project, and neither answer was "this course".
• You can say in one sentence what a neutral foundation home does not promise.
• You know where to read the pinned versions you would quote in an upstream issue: AGENTS.md.

Continue to 8.7. Capstone when you can route a bug to its owning project without reopening this page.